1. Field of the Invention
The present invention relates generally to network communication protocols and, more particularly, to an apparatus and method for enhancing reliability of streaming real-time data using the real-time transport protocol.
2. Description of the Related Art
The increase in connection speeds and bandwidth available to clients connecting to the Internet has allowed content providers to provide more multimedia content, in terms of both number of multimedia files and the size of such files, at their respective servers. The high bandwidths offered to clients by services such as cable modems and Digital Subscriber Lines (DSL) are a viable and desirable way to experience high-quality streaming multimedia content. To stream multimedia content over the Internet, a protocol is required as a basis for file transmission between the client and server.
A protocol is a set of rules that clients and servers use to communicate with one another over the Internet. The Internet Protocol (IP) is a packet based data protocol that all of the other current Internet protocols ride on top of. When a client request a file from a server on the Internet, the file is segmented into a plurality of successive packets that the server sequentially sends to the client. As each packet arrives at the client, the client reassembles the packets into a carbon copy of the original file.
In IP, each transmitted packet includes a header, which is a small piece of data minimally containing the IP address of the transmitting server and the IP address of the intended recipient client. The network hardware of the Internet routes the packets among varying paths to their intended destination using the client IP address in the header information. However, IP does not ensure that the packets arrive in the same order at the intended recipient client in which they were sent from the originating server, nor does IP ensure that any such packets arrive at all. Ensuring the delivery of packets to the intended recipient client is the function of the higher level protocols that ride on top of IP.
A protocol that does ensure that all packets arrive at the intended recipient client is the Transmission Control Protocol (TCP), which resides on top of IP and is commonly referred to as TCP/IP. TCP is specifically designed to add reliability and data integrity to the packet based nature of IP. When the client downloads a standard file from the Internet, for example, a software application or text document, TCP requires that incoming packets must be put together in the order they were transmitted from the server to ensure the file can be read or executed properly. If any packets are missing from the downloaded file, the file is corrupt and most likely rendered unusable.
A feature of TCP is that it establishes a temporary direct connection between the intended recipient client and the transmitting server to facilitate that the packets are received in the order they were sent. TCP accomplishes this feature by adding at the server additional header information to outbound packets, basically numbering each of them so the receiving client can determine their proper sequence. Another feature of TCP is that if a packet goes missing, all activity at the recipient client is halted until the missing packet is re-transmitted from the server and received at the client. Accordingly, TCP advantageously provides for retransmission of missing packets.
Although TCP/IP is highly advantageous to download standard data files and executable applications wherein file corruption is not tolerable, the limitation of extra time TCP imposes to retransmit lost packets and also to wait for all packets to arrive disadvantageously renders TCP/IP relatively slow. Another limitation of TCP/IP is that the recipient client must wait until the file being received is completely downloaded before the client can access it, thereby disadvantageously rendering TCP unusable for real-time streaming multimedia content. TCP is inherently limited in this respect since, should any part of the file be missing, the subsequent part of this file is unreadable.
For example, using TCP/IP, the client cannot start downloading multimedia content simultaneously with simultaneous playback being accomplished by a client multimedia player reading the content as it is being downloaded. One known exception to this limitation of TCP/IP exists, which is the ability of certain MP3 players to begin playing MP3 files before they are completely downloaded. However, only the partial file that existed in the client file system as a result of the downloading process at the time the media player was started to read the content can be accessed. The new content that continues to be downloaded while the partial file is being played, although being stored in the client file system, cannot be accessed until the file is reloaded into system memory by restarting the media player to read this file. However, even if our packet remains missing, no packets thereafter can be played or viewed until such packet is retransmitted.
A common protocol that is, however, more adaptable to delivery of multimedia content is the User Datagram Protocol (UDP). Similarly to TCP, UDP rides on top of IP, adds a sequence number to the header information for each packet, and is also commonly be referred to as to UDP/IP. In contrast to TCP, UDP does not establish a direct connection between the server and client. Although the server sequentially transmits packets into the Internet, the connectionless feature of UDP results in packets being received at the intended recipient client not necessarily in the same order as transmitted. As each sequentially numbered packet is transmitted into the Internet, it may be routed along different paths from each other packet, as determined by network congestion. Furthermore, in UDP, some packets may be lost in the network and not received at all.
A primary advantage to using UDP for the delivery of multimedia content is that, in the event that packets are lost, UDP allows the downloaded file to be assembled with the packets that have been received and resequenced from the sequence number in the header information to compensate for the lost packets. Another advantage to using UDP for the delivery of multimedia content is that, UDP being a connectionless protocol, a server may send identical content to multiple recipient clients simultaneously. A disadvantage to UDP is that lost packets may, depending on the information content of such loss packets, result in glitches, stutter or jerkiness of the media content when played back.
The Real-time Transport Protocol (RTP) has been developed for the streaming of multimedia content. RTP takes advantage of UDP and attempt to overcome UDP's disadvantages by adding an extra layer of functionality and rules to server transmitted packets that enhances the delivery of streaming multimedia. Although RTP preferably rides on top of UDP, RTP is designed to ride on top of any other transport layer protocol, and is not inextricably linked to UDP.
RTP utilizes the connectionless packet transmission of UDP/IP and adds a timestamp to the header information of the packets that lets software on the other end reorder packets more efficiently. The timestamp labels a packet with the time it was transmitted, but a single timestamp can also span several packets that are transmitted close together. If some of these packets are lost or received out of order, the timestamp information combined with the sequence numbers in the header facilitate re-sequencing and playback of the media content.
With RTP, when a streaming file is requested, the client media player determines the minimum sustained transfer speed the RTP connection supports and creates a buffer for incoming packets so that the media player can read from the buffer while further packets are still streaming in. For example, the media player may wait until 20% of the requested file you requested is downloaded before it begins playback of the file. While the media player is reading the 20% of the file that has been placed in the buffer, incoming packets are replenishing what is taken. Ideally, an equilibrium is obtain such that the incoming packets replenish the same amount of content as is being read. Otherwise, should the buffer empty completely, the media player may need to pause until the buffer has been replenished. Accordingly, an advantage of RTP over TCP and UDP is that the recipient client can assemble a partial file from the downloaded packets and the client media player can read the file content and produce output from a partially downloaded incoming file while the rest of the packets are still arriving, but still stream those new packets without having to reload the entire file.
A further advantage of RTP is the ability to deliver real-time multimedia content, for example live broadcasts, and transmit such real-time content as an unknown overall quantity of packets and which need not be first saved as a file. A limitation of RTP, however, is that even with a generous buffer in place, RTP may be unable to handle streaming data if, in the event RTP could be enhanced to include a retransmission of packets mechanism similar to TCP/IP, it waited for lost packets to be re-transmitted. The length of time RTP may be required to wait for a lost packet to be transmitted may cause the buffer to be seriously depleted. Depletion of the buffer may in turn require packets to be read as received, or pause the media player until the buffer has been replenished. Furthermore, RTP is disadvantageously slow in determining at the server whether available bandwidth for transmitting packets has been exceeded. Accordingly, if a packet traveling over a RTP connection gets lost, it stays lost, and the media player makes do without it. However, lost packets disadvantageously cause stutter, jitters or pausing in the played back content.